Business Analyst Community & Resources | Modern Analyst

Explain the Data Mesh paradigm and contrast it with a Centralized Data Lake

Adrian M. — Tue, 17 Jun 2025 04:11:00 GMT

Data Mesh is an organizational and architectural paradigm that treats data the way modern DevOps treats software: small, cross-functional domain teams own, build, and run “data products.” A data product is a well-documented, quality-assured dataset (or API/stream) with clear SLAs, discoverable through a shared catalog.

Data Mesh rests on four principles:

Domain-oriented decentralization – each business domain (e.g., Loan Origination, Fraud Detection) is accountable for the data it generates.

Data as a Product – teams deliver trustworthy, versioned data with defined consumers, not raw “exhaust.”

Self-serve data platform – a common toolbox (storage, pipelines, governance-as-code) that domain teams can spin up without depending on a central data team.

Federated computational governance – global standards (schemas, lineage, PII policies) enforced automatically so decentralization doesn’t become chaos.

A Data Lake is a single, enterprise-wide repository—often Hadoop, S3, or Azure Data Lake—into which raw data from every source is ingested “as is.” A central platform team governs schema management, ingestion tooling, and security, while downstream analysts query or transform the data for specific needs.

Dimension	Data Mesh	Centralized Data Lake
Ownership	Domains own and serve their data	Central data team owns ingestion and curation
Scaling Model	“You build it, you run it” scales with org size	Central team becomes bottleneck as sources and use cases grow
Data Quality	Built-in—quality gates live where data originates	Often deferred; raw dumps rely on downstream cleaning
Time-to-Insight	Faster for domain-specific questions; teams iterate locally	Slower for new sources while central team builds pipelines
Governance	Federated standards enforced via platform tooling	Centralized governance; easier to audit but can slow change
Skill Requirements	Data engineering knowledge distributed across domains	Deep expertise concentrated in platform team
Cost & Duplication	Higher in short term (duplicate tooling & skills)	Lower tooling duplication but higher coordination overhead

Use Data Mesh when the organization is large, domains are autonomous, and analytics demand outpaces what a single platform team can supply.

Stick with a centralized lake when data volumes are huge but use cases are still exploratory, or when tight regulatory control favors one gate-keeping team.

What is Data Literacy?

Adrian M. — Tue, 15 Apr 2025 04:37:00 GMT

Data Literacy refers to the ability to read, interpret, create, and communicate data accurately. It encompasses understanding how data is generated, manipulated, and analyzed, as well as recognizing the limitations, biases, and ethical considerations tied to data use. In today’s data-driven world, Data Literacy is essential for making informed decisions, whether you’re a frontline employee interpreting a sales dashboard, an executive gauging market trends, or a business analyst designing comprehensive reports.

A key component of Data Literacy is data interpretation - the skill to draw meaningful insights from raw information. This means going beyond simply glancing at spreadsheets or charts: it requires asking the right questions, identifying patterns, and understanding the context behind the numbers. For instance, a spike in web traffic might look promising at first glance, but without analyzing bounce rates or user demographics, it’s difficult to conclude whether the traffic surge represents long-term growth or a fleeting anomaly.

Equally important is the ability to challenge data sources and assumptions. Not all data is of equal quality, and biases can creep in through how it’s collected or interpreted. A data-literate professional knows to question the accuracy, recency, and representativeness of the information they’re using. This critical thinking skill ensures that subsequent decisions are grounded in trustworthy data rather than misleading or incomplete figures.

From a Business Analyst’s perspective, Data Literacy is pivotal for bridging the gap between raw data and actionable insights. Business Analysts frequently serve as the “translators” in an organization—converting complex datasets into understandable visualizations or narratives that stakeholders can use to make strategic choices. Without a high degree of Data Literacy, it’s challenging to create meaningful dashboards, anticipate market trends, or perform root cause analyses effectively.

Moreover, as organizations increasingly adopt advanced analytical methods—such as predictive modeling or artificial intelligence—Data Literacy becomes even more important. Analysts and decision-makers alike need to understand not only what the models are predicting but also how those predictions are generated. This includes interpreting algorithms, assessing potential biases, and evaluating whether the outputs align with ethical and regulatory standards.

Ultimately, Data Literacy is about more than just numbers: it’s about equipping professionals with the skills and mindset to approach data thoughtfully, responsibly, and confidently. In doing so, organizations can leverage their information assets to drive innovation, optimize operations, and make decisions that truly reflect the realities of a rapidly evolving marketplace.

What is Data Mapping?

Adrian M. — Mon, 10 Mar 2025 00:34:00 GMT

Data Mapping is the process of connecting data fields from one source to another, ensuring data consistency, accuracy, and proper transformation. It is a crucial step in data integration, migration, and transformation projects, enabling seamless data exchange between systems, databases, or applications.

Key Aspects of Data Mapping

Source and Target Definition – Identifying the structure and format of the data in the source system and mapping it to the corresponding fields in the target system.
Transformation Rules – Defining how data should be modified, standardized, or cleaned before being transferred.
Mapping Techniques – Methods include manual mapping, schema mapping, and automated mapping tools using AI or machine learning.
Validation & Testing – Ensuring that the mapped data maintains accuracy, integrity, and consistency after the migration.

Example Data Mapping Use Cases

ETL (Extract, Transform, Load) Processes – Mapping data from multiple sources into a data warehouse.
System Migrations – Transferring customer records from an old CRM to a new one.
Regulatory Compliance – Ensuring data fields meet compliance standards (e.g., GDPR, HIPAA).

Example from the Credit Card Industry

A credit card company migrating customer transaction data from an old processing system to a new fraud detection platform needs to map fields such as:

Cardholder Name (source: Customer DB → target: Fraud Detection System)
Transaction Amount (source: Merchant DB → target: Risk Analysis System)
Card Number (source: Payment Processor → target: Encrypted Storage in Compliance System)
Transaction Date/Time (source: POS Terminal → target: AI Fraud Detection Model)

Proper data mapping ensures that real-time fraud detection is accurate, transactions are processed correctly, and regulatory requirements (e.g., PCI DSS, GDPR) are met.

Why Data Mapping is Critical for Business Analysts

For business analysts, data mapping is essential because it serves as the foundation for effective data-driven decision-making, system migrations, and regulatory compliance. Without accurate data mapping, organizations risk data inconsistencies, financial errors, security breaches, and compliance violations—especially in industries like credit card processing, where data integrity is paramount.

By understanding and implementing strong data mapping strategies, business analysts help organizations:

Improve data accuracy and consistency across systems.
Reduce operational risks and prevent costly errors.
Ensure regulatory compliance and data security.
Enable seamless system integrations for improved business performance.

Thus, data mapping is a critical skill for business analysts as it directly impacts business efficiency, customer trust, and regulatory compliance.

Why Are Good Data Definitions Important?

Adrian M. — Mon, 30 Dec 2024 00:21:00 GMT

Good data definitions are crucial in any business environment, especially for a business analyst, as they ensure consistency, clarity, and accuracy in data usage across an organization. Data definitions provide a clear understanding of what each data element means, how it should be interpreted, and how it fits into broader business processes. Without clear definitions, data can be misinterpreted, leading to flawed insights, poor decision-making, and operational inefficiencies.

One of the primary reasons good data definitions are important is that they establish a common understanding across teams and departments. In large organizations, different teams—such as marketing, finance, operations, and IT—often work with the same data but may interpret it differently. For example, the definition of "customer" could vary across departments: for marketing, it might refer to anyone who has shown interest, while for finance, it could refer to someone who has made a purchase. Without a standardized definition, the analysis might lead to conflicting conclusions and inefficiencies in decision-making.

Clear data definitions also promote data quality and consistency. When data is well-defined, it is easier to capture, validate, and maintain. This consistency is particularly important when working with large datasets or when data is aggregated from multiple sources. For instance, if different systems or departments collect data using varying definitions or formats, it can lead to discrepancies that affect the integrity of reports or analysis. Standardized definitions help mitigate these risks, ensuring that the data is accurate and reliable.

Moreover, good data definitions are essential for effective data governance. A well-documented data dictionary or metadata repository ensures that data is properly classified and governed throughout its lifecycle. It also aids in compliance with regulations, as proper definitions ensure that data is handled appropriately, particularly in sectors where privacy and security are critical, such as healthcare or finance.

For business analysts, having clear data definitions is vital when deriving insights or making recommendations. Well-defined data enables the creation of more accurate models, forecasts, and reports, which are essential for business strategies. It helps analysts ensure they are using the right metrics to measure performance, leading to actionable, data-driven decisions that align with business goals.

What is ACID in Database Design?

Adrian M. — Mon, 10 Jun 2024 00:23:00 GMT

ACID is an acronym that stands for Atomicity, Consistency, Isolation, and Durability. These are the four key properties that define the reliability and integrity of transactions in database systems. They ensure that all operations are processed correctly, consistently, and remain durable, providing a strong foundation for data integrity and trustworthiness in critical applications.

Here is a summary of each component of ACID:

Atomicity - Atomicity ensures that each transaction is treated as a single, indivisible unit of work. This means that either all operations within the transaction are completed successfully, or none of them are. There is no partial completion.
- Atomicity prevents the database from being left in an inconsistent state.
- Example: in a banking system, if a transaction involves transferring money from one account to another, atomicity ensures that both the debit and credit operations occur together. If either operation fails, the transaction is rolled back, leaving the system as if the transaction never happened.

Consistency - Consistency ensures that a transaction brings the database from one valid state to another, maintaining database rules and constraints. Before and after the transaction, all data must conform to the defined rules, such as unique keys, foreign keys, and other integrity constraints.
- Consistency guarantees that the database remains in a valid state even in the presence of failures.
- Example: in an e-commerce system, consistency ensures that product inventories are correctly updated and do not allow negative stock levels or violate business rules.

Isolation - Isolation ensures that concurrently executing transactions do not interfere with each other. Each transaction should appear as though it is the only transaction in the system, even when multiple transactions are happening simultaneously.
- Isolation prevents issues such as dirty reads, non-repeatable reads, and phantom reads, which can lead to incorrect or inconsistent data.
- Example: in a multi-user system, isolation ensures that one user's transaction does not affect another user's transaction in unpredictable ways.

Durability - Durability guarantees that once a transaction has been committed, it will remain so, even in the event of a system crash or power failure. The changes made by the transaction are permanently recorded in the database.
- Durability ensures that committed data is never lost.
- Example: after a purchase transaction is completed and confirmed to the user, durability ensures that the purchase record remains in the database despite any subsequent failures.

What are some of the key database constructs that a business analyst should be familiar with?

Adrian M. — Sun, 10 Mar 2024 05:29:00 GMT

All organizations deal with data and every business analyst should have at least a basic understanding of the key database constructs in order to be an effective analyst. Some of the most important constructs are:

Tables - Tables are the fundamental structure in a relational database, representing entities or concepts. Each table consists of rows (records) and columns (fields) that store specific pieces of information.

Columns - Columns, also known as fields or attributes, represent the vertical aspect of a table. Each column defines a specific type of data that can be stored in the table. For example, in a table storing employee information, columns might include "EmployeeID," "FirstName," "LastName," "Email," and "HireDate."

Data Types - Data types define the kind of data that can be stored in a column of a table. Common data types include integers, strings, dates, and binary data.

Rows - Rows, also known as records, represent the horizontal aspect of a table. Each row in the table corresponds to a single record or instance of the entity represented by the table. In the employee example above, each row would contain the actual data for a specific employee, with values for each of the columns defined in the table.

Indexes - Indexes are data structures that improve the performance of database queries by allowing for faster retrieval of data. They are typically created on columns frequently used in search conditions.

Keys - A "key" refers to one or more columns that uniquely identify each record within the table. There are several types of keys commonly used in database management systems:

Primary Keys - A primary key is a unique identifier for each record in the table. It ensures that each row can be uniquely identified and retrieved. Typically, a primary key consists of one or more columns, and its values must be unique and non-null for each record. Primary keys are used to enforce data integrity and establish relationships between tables in a relational database.

Foreign Keys - A foreign key is a column or set of columns in one table that refers to the primary key in another ta
ble. It establishes a relationship between the two tables, known as a foreign key constraint. Foreign keys are used to enforce referential integrity, ensuring that values in the foreign key column(s) match existing values in the primary key column(s) of the referenced table.

Alternate Keys - An alternate key is a unique identifier for each record in the table that is not chosen as the primary key. Alternate keys provide additional means of uniquely identifying records and are typically used for querying and data integrity purposes

Queries - Database queries are commands or instructions written in a specific query language (such as SQL - Structured Query Language) that are used to retrieve, manipulate, or manage data stored in a database. These queries allow users to interact with the database, perform various operations, and obtain specific information based on their requirements. Database queries can be categorized into several types:

Data Retrieval Queries - These queries are used to retrieve data from one or more tables in the database. They typically use the SELECT statement to specify the columns to retrieve and the conditions to filter the data

Data Manipulation Queries - These queries are used to modify or manipulate data in the database. They include INSERT, UPDATE, and DELETE statements to add, modify, or remove records from tables.

Data Definition Queries - These queries are used to define or modify the structure of the database schema. They include statements such as CREATE, ALTER, and DROP to create, modify, or delete tables, indexes, views, and other database objects.

Views - Views are virtual tables generated from the results of a data retrieval query. They allow users to access specific data without needing to know the underlying structure of the database.

Triggers - Triggers are database objects that automatically execute in response to certain events, such as INSERT, UPDATE, or DELETE operations on a table. They are often used to enforce business rules or maintain data integrity.

Stored Procedures - Stored procedures are a type of precompiled code or script that is stored in a database management system (DBMS) and can be executed by calling its name from within another script or application. They are commonly used in relational database management systems. Stored procedures are primarily written in SQL, but they may also include procedural programming constructs like loops, conditional statements, and exception handling.

What is CRUD?

Adrian M. — Mon, 24 Apr 2023 21:49:00 GMT

CRUD is an acronym which stands for Create, Read, Update, and Delete and it refers to the four basic operations which are supported by data-based compute systems. These are the four basic functions that can be performed when working with data in a persistent storage.

It also refers to operations that a user can perform using a given feature. With the exception of workflow, most business applications deal exclusively with user interfaces which allow the user to either create (enter), read (view), update (edit), or delete data.

Create - This operation refers to the process of adding new data to a database. This can be accomplished by creating a new record or row in a table within the database.
Read - This operation refers to the process of retrieving data from a database. This can be accomplished by querying the database and retrieving specific records or rows that match certain criteria.
Update - This operation refers to the process of modifying existing data in a database. This can be accomplished by updating the values of one or more fields within a record or row in a table.
Delete - This operation refers to the process of removing data from a database. This can be accomplished by deleting a record or row from a table within the database.

CRUD is an important concept in software design because it provides a framework for creating, managing, and interacting with data. Business analysts can use CRUD to help define and document the capabilities and needs for a business application:

Requirements Gathering - The business analyst can work with stakeholders to identify the data that needs to be managed in the system and define the requirements for creating, reading, updating, and deleting that data.
Use Case Modeling - The BA can create use case diagrams that illustrate how users will interact with the system to perform CRUD operations on data. This can help to identify any potential usability issues and ensure that the system meets the needs of its users.
User Interface Design - The business analyst can work with user experience designers to create a user interface that provides an intuitive way for users to interact with the system and perform CRUD operations on system's data.
Testing - The analyst can work with the testing team to define comprehensive test scenarios which ensure that the system properly supports the CRUD operations for managing data.

What is Data as a Product (DaaP)?

Adrian M. — Mon, 12 Dec 2022 03:19:00 GMT

“Data as a Product” or DaaP is a construct of the data mesh paradigm and it’s a way to look at the data within the enterprise as a product offered by the various data teams to the rest of the enterprise.

Data as a product is a combination of strategy and tools which look at data as a ready to consume product by internal customers.

Consider, for example, how you, as a consumer, make a simple purchase of a pair of shoes. In your shopping process you have come to expect the following:

Ability to search for different types of shoes
Ability to read details about a given show model (features, colors, options)
Ability to make customized selection when purchasing a pair of shoes (ex: size, color, width, etc.)
Ability to order the shoes you like and be able to specify where and how it should be delivered to you
Ability to receive the shoes in a reasonable amount of time and even expedited if you are willing to pay more

Data as a product works fairly similarly aka there is a provider of data (the seller), there is a customer looking for data (the buyer), and there is a way to acquire the data (the shopping system). This means that DaaP has a few characteristics such as:

Data moves one way (unidirectional) from the data provider (data engineers, data analysts, data scientists) to the consumer within the enterprise.

Data can be found in a data catalog where it can be easily searched and acquired/ordered.

There are different types of “data products” such as raw data, data models, ML data insights, etc.

Just with regular consumer products, a “Data as a Product” strategy needs to include both:

Tools - these are the delivery and “shopping” systems where data is made accessible to enterprise clients.

Mindset - is the customer-driven development of data products where the data providers work diligently to understand the needs of their customers and develop data products which are in high demand and of value to end users.

An advanced Data as a Product program will go to a lengths to establish a robust set of practices surrounding these data products including:

Data Product Development
Data Product Usability
Data Product Reviews
Data Product Support
Data Product Safety
Data Product Inventory
Data Product Quality
Data Product Marketing
etc.

We realize, there are many more nuances and definitions of data as a product. What is your point of view?

What’s the difference: On-Premise vs Cloud vs. Fog vs. Edge Computing?

Adrian M. — Mon, 10 Oct 2022 20:03:00 GMT

Before we jump into the comparison of on-premise vs. cloud vs. fog vs. edge computing we need to take a step back and use first principles thinking by first defining the terms in a stepwise manner.

Let’s start with what is computing? For our purposes, let’s keep it simple: it’s the activity or process performed by computing devices (hardware or software) in order to achieve a specific goal or objective. The types of computations very drastically but can include activities such as retrieving data, performing searches, executing algorithms, or making decisions.

The key difference between on-premise vs. cloud vs. fog vs. edge computing has to do with where the computing takes place.

What is a Data Flow?

Adrian M. — Tue, 16 Aug 2022 04:53:00 GMT

Data Flow Summary

From a business or systems analysis perspective a data flow represents data movement from one component to another or from one system to another. Another way of describing it: data flow is the transfer of data from a source to a destination. If we get more technical, an ETL (extract, transform, load) process is a type of data flow.

Components of a data Flow

Data Source(s) - These are the places where the data comes from. Each data flow has at least one, but it could have many sources of data. Some of the types of data sources an analyst might encounter include: database tables, XML files, CSV (comma separated values) files, spreadsheets, flat files,
Data Mapping - The process of matching fields from the source to the destination. Some may argue that data mapping is really data transformation but if the data is not being changed but only moved from one structure to another as part of the data flow, it’s just a mapping.
Data Transformation(s) - These are the activities which modify the source data before it reaches its intended destinations. The types of data transformations common in data flows include: merging of data, updating/enhancing the data, and splitting the data.
Data Sorts - These are processes/logic which change the order in which the data records arrive at the destination. For example the source table may contain the records in the order in which they were inserted/created but the destination needs them in alphabetical order by a given column.
Data Filters - Processes and logic which reduces the amount of data so that only the desired data records arrive at the data flow’s destinations.
Data Joins - The practice of correlating and combining data in separate tables or sources into a cohesive set, enhancing the meaning and richness of data as compared to the data from just once source. For example if one table contains customer ids and their names and another table contains customer ids and their phone numbers. By joining the two tables using the customer id as the correlating data element,, one can create a new data set which contains the customer id, customer name, and their phone numbers. Now I can actually phone the customer and call them by their name.
Data Destination(s) - These are the places where we want to put the data. The destination types in a data flow can be as diverse as the source types discussed above.

The data flows vary in type and complexity depending on their purpose/function:

Type

Examples

Simple Data Flow

Data mirroring of a table from one source to another is an example of a simple data transformation. Data mirroring involves making an exact copy of the data from the source to the destination, not just the values but also the structure. This type of data flow does not require any data mapping or data transformations.

Another example of a data flow is copying a spreadsheet file from one location to another.

Complex Data Flow

Complex data flows are those which involve data from multiple sources of different source types where the data is joined, transformed, filtered and then split into multiple destinations of different types.

Data Flow Diagramming

One useful tool in understanding the flow of data within a system or an organization is a diagram which shows the key elements (primarily sources and destinations) of the movement of data. The most common such data is the Data Flow Diagram (DFD) and it’s more specialized form, the Context Diagram.

Here are some useful resources:

Data Flow Diagram with Examples & Tips

What is Cardinality?

Adrian M. — Mon, 15 Aug 2022 02:46:00 GMT

Before we discuss cardinality as it is used with databases and data modeling, let’s first look at the origin of the adjective cardinal.

If you were to look up the word cardinal in the dictionary you will probably find something like:

Cardinal (adj) = of great importance; main; principal; essential

You’ve surely heard about the cardinal rule referring to the rule of most importance.

You probably also heard about cardinal numbers which are the basic numbers we all know (1, 2, 3, etc.) and use everyday.

Continuing with mathematics, we move on to cardinality:

Cardinality (noun) = the number of elements of a given set; for example, set B = {x, y, z} is set to have a cardinality of 3 because it contains three elements.

When discussing data values in a column of a database table:

Cardinality = to the number of unique values across all the rows.

When it comes to data in a given table, you might also here these two terms:

High Cardinality = having a larger number of unique values (compared to the total number of rows). A column containing the employee numbers of a company would have a high cardinality because the employee numbers are expected to be unique.
Low Cardinality = having a low number of unique values (compared to the total number of rows). A column containing the day of the week (Monday, Tuesday, Wednesday, …) for appointments in a doctor’s office would have a low cardinality because there will be countless appointments occurring on a given day of the week.

Now we are ready to move on to modeling - data modeling and database modeling - which is the subject of this question:

Cardinality = is a qualifier of the relationship between two logical entities (in data modeling) or between two tables (in database modeling) which specifies the numerical relationship (count) of rows in one table and rows in another table. The cardinality is expressed in relationship form such as: one-to-one or one-to-many.

For example, if you consider two simple entities Student and Course, it can be said that a Student has a one to many relationship to Course(s) because a student can enroll in more than one course at a time.

In practice, the cardinality of data modeling is visible in some sort of data model or diagram such as: Entity-Relationship Diagram (ERD) or UML Class Diagram.

Setting the diagramming methodology aside, the basic cardinality relationships are:

Cardinality	Simple Notation	Description	Example
one-to-one	1 - 1	One entity (or row in a table) can relate to only one entity (or row in another table).	One employee has only one social security number and, vice versa, a social security number belongs to only one employee.
one-to-many	1 - *	One entity (or row in a table) can relate to many entities (or rows in another table).	One order can contain many items.
many-to-many	* - *	Many entities (or rows in a table) can relate to many entities (or rows in another table).	Many students are enrolled in many classes and many classes can have many students.

In the above simple notation “1” means “exactly one” and “*” means “one or more”.

In data modeling cardinality, the above three basic relationships can get a bit more complex (but not too complex) by introducing the concept of optionality. Using an example above, while a student may be enrolled in a class she doesn’t have to. Maybe she’s taking a semester off. Similarly, while a class can have many students, it may not have any (if nobody signed up yet).

Let’s summarize the simple cardinality notation:

Notation	Definition
1	exactly one
0..1	zero or one
*	many (but at least 1)
0..*	zero or many

Finally, let’s put these in practice with a couple of more examples:

Example

Entities

Notation

Verbalization

Consider the relationship between customers and checking accounts at a bank. A customer can have many checking accounts but it may not have any. A checking account has to have at least one owner but it may have more than one.

Customer, Checking Account

* - 0..*

Many to Zero-or- Many

Now consider persons and driver’s licenses. A person may or may not have a driver’s license but a driver’s license belongs to only one person.

Person,

Driver’s License

1 - 0..1

One to Zero-or-One

Your turn: What are your thoughts on cardinality?

What is a database view and why should the business analyst understand it?

Chris Adams — Mon, 09 May 2022 16:00:00 GMT

While the business analyst usual works in the logical domain, understanding what a database view is and the advantages of using them can be helpful when the analyst is tasked with documenting requirements and creating specifications for reports and user interfaces that present data from database queries.

A database view is a stored query that returns data from one or more database tables. The stored query, or view, is a virtual table. Once you have defined a view, you can reference it just as you would any other table in a database. Since the view is the result of a stored query, it does not contain a copy of the data itself. Instead, it references the data in the underlying base tables.

Views provide a number of advantages:

A view can provide additional security. By creating a view and creating the necessarily privileges, you can ensure that the users are only able to retrieve and modify data that is exposed by that view. Users will not be able to see or access data in the underlying tables that is not exposed by the view.
Views can reduce query complexities. By creating and storing complex queries and exposing them in the form of a view, the data from the view can be extracted using much simpler queries.
Since a database view is a stored query, not a copy of the actual data, views consume very little space.

Some examples of the ways views are used are:

To combine data from multiple tables into a single virtual table that can be queried using basic statements.
To partition a complex table into multiple virtual tables that are simpler to query. For example, if a database table contains sales data from the past 10 years, views can be created and represented using tables names such as SalesData2020 or SalesData2021.
To aggregate data and perform calculations. The view (stored query) can request the database engine to sum or average data in underlying tables. These sums or averages can then be queried more easily.

How do you gain a sufficient understanding of an industry in which you previously had no experience?

Chris Adams — Mon, 13 Jul 2020 16:00:00 GMT

The Business Entity Model and Context Diagram are two tools that give the business analyst a quick yet sufficient understanding of a new industry. They provide a high-level, overarching view of the space with the least amount of time investment possible.

Why are modeling techniques so important to Business Analysts, and how do you choose the right ones for your project?

Chris Adams — Mon, 08 Jun 2020 17:30:00 GMT

Grouping related items (whether requirements, ideas, business processes, etc.) into a diagram or model is just a way of forming them into recognizable and (hopefully!) familiar patterns. And the short-term memory limit is much less constraining if people are asked to remember and absorb a few different patterns as opposed to dozens of individual bits of information.

What are the most common types of data analytics, and what is the purpose of each type?

Chris Adams — Mon, 08 Jun 2020 17:10:00 GMT

There are three main types of data analytics, with increasing levels of complexity: Descriptive analytics, Predictive Analytics, Prescriptive Analytics. The value of each type is relevant to the nature of the business problem to be solved. Each type of analysis offers different information and insights to address different business needs.

How do you ensure all business processes have been accurately identified and captured?

Chris Adams — Sat, 07 Mar 2020 22:21:00 GMT

How can a business analyst ensure that ANY discovery process yields complete results? The short answer is to use multiple complementary techniques to approach a problem from different angles where each validates the other and fills any gaps in the discovery process.

What is a logical data dictionary and what are the benefits of maintaining one?

Chris Adams — Sun, 11 Aug 2019 18:00:00 GMT

A data dictionary, also commonly called a metadata repository, is a centralized repository of data elements and other metadata about them. This may include the meaning of a piece of data, relationships to other data, origin, usage, type and length.

In which document do you include the Class Diagram (business requirements, functional requirements, software specification document)?

sonavi — Mon, 12 Nov 2018 16:20:00 GMT

Just like any other diagram, the Class Diagram is just a tool at the disposal of the analyst. In the absence of a set process, it is at the analyst’s discretion to determine when to use a class diagram. Therefore, in which analysis artifact/document a class diagram should be included depends on its use.

What is a Sentiment Score Chart and when might a business analyst use one?

Chris Adams — Sun, 14 Oct 2018 18:46:00 GMT

Business Analysts engage in all kinds of interviews, open response surveys, ideation workshops, and other research activities that result in large amounts of qualitative information. So much qualitative information can present challenges both in terms of absorbing and understanding the information as well as representing it visually to others. It can be difficult to turn participants’ open responses into quantitative data. A sentiment score chart is a polarized histogram that communicates both the positive and negative feedback (or sentiment) of the participants transforming qualitative data into a quantitative visualization.

What is Gap Analysis?

Chris Adams — Sun, 13 May 2018 21:39:00 GMT

Gap Analysis is the process of comparing two things in order to determine the difference or “gap” that exists between them. Once the gap is understood, the steps required to bridge the gap can be determined.

What is the One Metric That Matters and how can it be used to improve a product?

Chris Adams — Mon, 12 Feb 2018 18:51:00 GMT

The One Metric That Matters (OMTM) is a minimalist approach that helps achieve this goal. OMTM is a mindset and guideline more than a rule. In practice, focusing on a single metric may be too restrictive to result in actionable data but this approach can be modified in a couple of useful ways. One is to identify a single metric for each facet of a product. Another is to focus on a single metric for a day, a week, or a month and optimize performance based on that single metric over that period of time.

Describe the difference between univariate, bivariate and multivariate analysis?

Chris Adams — Sun, 10 Dec 2017 23:08:00 GMT

Univariate analysis is the simplest form of data analysis where the data being analyzed contains only one variable. Since it's a single variable it doesn’t deal with causes or relationships. The main purpose of univariate analysis is to describe the data and find patterns that exist within it

What types of actions can help the business analyst avoid Analysis Paralysis?

Chris Adams — Sun, 12 Feb 2017 22:10:00 GMT

Analysis Paralysis is the dreaded black hole of projects. So, how do you recognize that you might be in Analysis Paralysis. Here are a few symptoms that might clue you in.

What are the benefits of a developing a business entity model early in the analysis process?

Chris Adams — Sun, 10 Jul 2016 21:00:00 GMT

There are numerous benefits to developing a business entity model (also called a logical data model), early in the analysis process. To understand these benefits, the information captured in the business entity model needs to be understood.

What is a Fact Model?

Chris Adams — Sat, 12 Mar 2016 18:00:00 GMT

A Fact Model is a static model which structures business knowledge about core business concepts and business operations. It is sometimes called a business entity model.

What is RML (Requirements Modeling Language)?

Chris Adams — Sun, 10 May 2015 23:02:00 GMT

Requirements Modeling language is a collection of diagrams used to model software from the business analysis or product management perspective.

What information should be included in a logical data model?

Chris Adams — Fri, 06 Jun 2014 04:21:00 GMT

A logical data model is a graphical representation of data that is created or used by the organization, and associated rules governing the structure and relationships of that data. The logical model should use business names (following any established enterprise data or naming standards), and should be independent of any technology or physical design considerations. It typically includes the following information:

Entities (“tables”)

Relationships between entities

Cardinality – the numeric relationship between occurrences of two related entities

Attributes (“fields”) that are relevant to the project. (The logical data model does not include details such as data-types or foreign keys, since those are physical design considerations.)

--
Sandy Lambert
Business Architect
LinkedIn Profile

What is metadata, and why is it important to a BA?

Chris Adams — Fri, 08 Nov 2013 22:33:00 GMT

Metadata is defined as “data about data”. Metadata describes the context, use, and validity of business information. Metadata requirements and definitions are an important part of the data requirements to be captured by the Business Analyst for any new system. Effective collection, maintenance and reporting of metadata support organizational needs to monitor and manage the integrity, quality and accuracy of its data.

Common metadata attributes include the date and time that data was collected or changed, and the data source or identification of the person who performed the change. Metadata attributes for an electronic document or record may include the type of record, its retention period, and its security classification or category.

--
Sandy Lambert
Business Architect
LinkedIn Profile

What is SQL and would a business or systems analyst use it?

Chris Adams — Mon, 09 Jul 2012 05:45:00 GMT

SQL is a standard scripting language designed for managing data in relational database management systems. SQL stands for Structured Query Language. SQL became an ANSI standard in 1986, and an ISO standard in 1987. Since SQL is a standard, a working knowledge of the SQL language used on one major RDBMS (Relational Database Management System), such as MySQL or DB2, can be leveraged for others. However, issues still exist with portability of the actual SQL code from one RDBMS to another. This is typically attributed to the RDBMS not being fully compliant with the standard, or the standard has been interpreted differently. Still, the variation of SQL used doesn’t usually vary too significantly from one RDBMS to another.

It’s helpful for analyst to have a limited theoretical knowledge of the capabilities of SQL. This includes SQLs ability to create and drop (delete) database table in order to create and modify the database schema, insert new data or update the existing data within table columns, query the data, and manage data access.

While much of the capabilities of the SQL language go beyond that which a business or systems analyst would need to understand in detail, it often helps for analysts to learn the specifics of SQL querying using SELECT statements. This allows the business analyst to perform a certain amount of data analysis and testing on their own.

The following is a sample SELECT statement where data is being selected from the “isbn”, “title”, and “price” columns of the “Book” table:

SELECT isbn, title, price, price * 0.06 AS sales_tax
    FROM Book
    WHERE price > 100.00
    ORDER BY title;

What is a Database Index?

Chris Adams — Mon, 09 Jul 2012 05:41:00 GMT

A database index is a data structure that is created to provide a fast and efficient means of finding data rows in tables. You can picture this the same way an index of a book helps you find specific material quickly.

In a relational database, an index is a copy of one part of a table. Indices can be created using one or more columns of a database table. However, a simplified visualization of an index would be to picture it as a separate table with one column containing a key value and a second column containing a pointer to (or the location of) the row within a table containing the same key value. The index entries are maintained in key sequence. This provides for faster querying using various types of search technique that deliver non-linear response times. Some databases also allow indices to be created only for records that satisfy some conditional expression.

Some fields are automatically indexed by the DBMS. Primary keys and fields marked as ‘unique’ fall into this category. This is done to aid in the efficiency and quick enforcement of constraints. If a field such as social security number or email address is marked as ‘unique’ then the database will create and use the index to ensure that data is not introduced which conflicts with this constraint.

There are drawbacks to database indices as well. Database indices take up storage space. They also make for slower data insert, updates, and deletes since both the data within the tables and the indices need to be updated.

How do you define a database transaction?

Chris Adams — Mon, 13 Feb 2012 05:18:00 GMT

Business analysts who work on system solutions should have a basic understanding of database concepts. Many databases are part of a class of systems called OLTP (OnLine Transaction Processing) systems. So what is a database transaction within this context?

A database transaction is a series of operations performed within a database management system against a database such that, once completed, the data is left in a reliable and consistent state. If any step of the transaction fails then all steps are reversed (rolled back), so that data integrity can be maintained.

Database transactions serve two main purposes. First, to conduct and bundle units of work that allow for accurate recovery of data in the case of system failures. Second, to provide isolation between different programs which may attempt to access the data simultaneously.

A database transaction should conform to the principles described by the acronym ACID (Atomic, Consistent, Isolated and Durable).

Atomic means that a series of database operations either all occur, or nothing occurs. Atomicity avoids partial database updates which can cause issues with data integrity. Atomic transaction can be described as indivisible and irreducible. Transactions, while atomic, can make updates to multiple database stores operating on multiple systems.

Consistent refers to the idea that a transaction will bring the database from one valid state to another and that the data written to the database will conform to defined rules. The rules can consist of constraints, triggers, and cascades. However, understanding these additional concepts go beyond what is necessary for this definition.

Isolated describes keeping changes made by one transaction hidden from other concurrently running transactions and operations until such time as they should be made visible based on defined rules.

Durable means that any transactions that have been committed to the database will survive permanently. This level of guarantee is often achieved by copying all transactions into a transaction log on a secondary storage medium. A transaction is considered committed only after it has be copied to the transaction log.

What are OLTP systems?

Chris Adams — Mon, 13 Feb 2012 05:17:00 GMT

OLTP or On-Line Transaction Processing systems are a class of systems which contain current, operational data used to control and run fundamental business tasks. OLTP systems are typically characterized by their ability to complete many concurrent database transactions and are designed for optimal database transaction speed. Additions and changes to data are user initiated (rather than scheduled) and conducted via short, atomic transactions.

Queries of OLTP systems are typically simple and return relatively few records. The structure of OLTP databases are highly normalized which means tables and fields are organized to minimize data redundancy and dependency. But this doesn’t lend itself to efficient processing of complex queries. More complex querying is typically run against historical data stores which are classified as OLAP systems (On-Line Analytical Processing) or Data Warehouses.

Transaction and data recovery is paramount for OLTP systems since they deal with current business data used to conduct real-time business operations. Similarly, OLTP systems are often decentralized to avoid single points of failure. This can also help spread volume over multiple servers to maximum the volume transaction processing possible and minimize response times.

What is a Context Diagram and what are the benefits of creating one?

Chris Adams — Sun, 11 Jul 2010 18:55:00 GMT

The Context Diagram shows the system under consideration as a single high-level process and then shows the relationship that the system has with other external entities (systems, organizational groups, external data stores, etc.).

Another name for a Context Diagram is a Context-Level Data-Flow Diagram or a Level-0 Data Flow Diagram. Since a Context Diagram is a specialized version of Data-Flow Diagram, understanding a bit about Data-Flow Diagrams can be helpful.

A Data-Flow Diagram (DFD) is a graphical visualization of the movement of data through an information system. DFDs are one of the three essential components of the structured-systems analysis and design method (SSADM). A DFD is process centric and depicts 4 main components.

Processes (circle)
External Entities (rectangle)
Data Stores (two horizontal, parallel lines or sometimes and ellipse)
Data Flows (curved or straight line with arrowhead indicating flow direction)

Each DFD may show a number of processes with data flowing into and out of each process. If there is a need to show more detail within a particular process, the process is decomposed into a number of smaller processes in a lower level DFD. In this way, the Content Diagram or Context-Level DFD is labeled a “Level-0 DFD” while the next level of decomposition is labeled a “Level-1 DFD”, the next is labeled a “Level-2 DFD”, and so on.

Context Diagrams and Data-Flow Diagrams were created for systems analysis and design. But like many analysis tools they have been leveraged for other purposes. For example, they can also be leveraged to capture and communicate the interactions and flow of data between business processes. So, they don’t have to be restricted to systems analysis.

A sample Context Diagram is shown here.

A Context Diagram (and a DFD for that matter) provides no information about the timing, sequencing, or synchronization of processes such as which processes occur in sequence or in parallel. Therefore it should not be confused with a flowchart or process flow which can show these things.

Some of the benefits of a Context Diagram are:

Shows the scope and boundaries of a system at a glance including the other systems that interface with it
No technical knowledge is assumed or required to understand the diagram
Easy to draw and amend due to its limited notation
Easy to expand by adding different levels of DFDs
Can benefit a wide audience including stakeholders, business analyst, data analysts, developers

What approach should be taken when creating a Context Diagram? Top down? Bottom up?

Chris Adams — Sun, 11 Jul 2010 18:44:00 GMT

A number of factors should be considered when deciding what approach to use (top down or bottom up) to create a Context Diagram. First let’s be clear about what each approach means.

The top-down approach: this approach refers to starting directly with the Context Diagram and creating it from scratch. This is done by placing the system under consideration in the center and then identifying each of its interactions based on either the analyst’s current knowledge or by asking others who may have the knowledge.

The bottom-up approach: this approach refers to starting with a lower level data-flow diagram, identifying known processes and the data that flows between them, and then following the data trail to uncover other unknown processes. After the lower-level data-flow diagram is completed, the processes can be rolled up to the system level.

The top-down approach is a more direct approach and is often the direction many analysts choose to take (whether right or wrong for their particular situation). It can work well under some circumstances, particularly if the system under consideration has only a few interactions with external entities or if the same analysts support the application on an ongoing basis and are very familiar with all of the possible interactions and dependencies that the system has. But if the system has a very large number of interactions and dependencies or if the analyst is unfamiliar with the system then this approach can be difficult. The less informed analyst would need to rely on a very iterative approach where the context diagram is evolved over time by reviewing it with a number of subject matter experts that understand pieces of the environment.

The bottom-up approach is a less direct method, but can be exceptionally valuable as an investigative technique. Starting with a lower-level data flow diagram allows the analyst to document the bits and pieces of the system that are understood and then follow the data to identify the various system interactions and dependencies that exist. This tends to be a more natural approach as it uses the power of the technique to document the entire scope of the system and its surrounding environment. In the top-down approach it can be difficult to know when the analyst has reached completion since it’s hard to know that which you don’t know. In the bottom-up approach the data-flow diagramming technique itself drives the analyst to a state of completion.

What is an XML Schema and what is its purpose?

Chris Adams — Sun, 09 May 2010 20:46:00 GMT

An XML Schema is a document that is itself described using XML and which defines how an XML document must be structured in order to conform to structured required by the a system or service which references the XML Schema. Specifically it defines:

The elements that may appear
The attributes that may appear for each element
Which elements are child elements
The order in which child elements must appear
The number of child elements that may appear
The data types for each element or attribute
Default values and constant value for elements and attributes
Minimum and maximum occurrences of an element

The term DTD (Document Type Definition) is often used when discussing the acceptable form of XML documents. However, XML Schemas are successors to XML DTDs and have a number of benefits over DTDs. Some of these benefits are:

Schemas are written in XML
Schemas may be extended to future additions
Schemas contain a richer set of rules to which data must conform
Schemas make it easier to validate correctness of data
Schemas support data types

XML schemas are able to enforce specific rules and data conformity such as:

Data Types – data conforms to a specific data type (string, date, numeric, boolean, etc)
Value restrictions – data conforms to the acceptable values (enumeration, fractionDigits, length, maxExclusive, maxInclusive, maxLength, minExclusive, minInclusive, minLength, pattern, totalDigits, whitespace, etc)
Element Indicators – elements conform to specific indicators (Order Indicators, Occurance Indicators, and Group Indicators) which apply rules to how many elements must appear, in what order, or adhering to a specific structure (maxOccurs, minOccurs, all, choice, sequence, etc).

Sample XML Schema

targetNamespace="http://www.somesite.com"
xmlns="http://www.somesite.com"
elementFormDefault="qualified">

Sample XML which conforms to Schema

   Joseph
   Smith
   Brian
   James
   56

Is it the job of a business analyst or systems analyst to draw the class diagram?

ModernAnalyst.com — Sat, 17 May 2008 06:00:00 GMT

It depends, it depends, and it depends!

As for most questions in business analysis, there isn’t only one answer. Whose job is to create a class diagram depends on the purpose of the class diagram.

First of all, the question implies that there is only one class diagram for a given project: “The Class Diagram”. For the most part, this is not the case. On some projects there may be a multitude of class diagrams while in others there may be none.

Second, the question implies that only one of the person/role on a given project would be task with creating class diagram. This is also not the case! There are many folks (business analyst, systems analysts, developers, etc.) who might have the need to create a class diagram in order to communicate a given concept or to solve a given problem.

So let’s rephrase the question:
“Who would use a class diagram and why?”

The business analyst might chose to create a class diagram in order to model the business domain showing the things of the business (the business domain/industry specific nouns found in the business lingo).

The systems analyst could use a class diagram to develop the logical data model for the system being designed.

The developer may also use a class diagram but for a different purpose: to show the actual classes, interfaces, and types being implemented in a given system.

Are there scenarios where the developers will produce something different from your requirements spec, and how would you handle this?

Emy — Sun, 13 Jan 2008 15:46:00 GMT

Yes, there are instances when the developers will produce something different than what the requirements or functional specification documents contain. Here are some of the instances/causes of such differences:

The specifications are ambiguous or incomplete and they can be easily interpreted in multiple ways. In this case, the developer may have simply misinterpreted the ambiguous requirement in a different way than what was intended.
The developer simply ignored the specification and/or just read it quickly and then developed the system from memory.
The development team encountered technical limitations and the system cannot be developed exactly the way they were specified.

In general, the best way to handle this is to have a clear process in place to manage differences between the specification and the developed product. This would require a strong QA team and QA process. Here are some more detailed which address the three items above:

First and foremost, ensure that the business analysis team has documented guidelines for creating requirements and functional specifications as well as processes in place for peer and management review of analysis artifacts to ensure they are accurate and unambiguous. In addition, since the QA team is responsible for creating test cases and scenarios based on the requirements and functional specifications, they should look for, find, and document as spec defects (bugs) those areas of the analysis artifacts which are ambiguous or are missing information. These defect reports can be used by the analysis manager to identify areas of improvement and also to provide performance feedback to the individual business systems analyst.
Create a process in the development team for each developer to be accountable for his/her deliverables and produce code which is defect free. In addition, the QA team should be able to find these discrepancies and create defect reports (bugs) for the development team to fix.
A process should be in place to deal with instances when the requirements cannot be implemented as outlined in the functional specifications. Have the development team review the functional specs and provide feedback before the coding starts. The development team should be a key stakeholder and reviewer of the analysis artifacts. The feedback can then be incorporated back into the analysis artifacts and, hopefully, resulting in the alignment of the specifications and developed product.

Why bother developing data models and why in Third Normal Form (3NF)?

Guy Beauchamp — Mon, 10 Dec 2007 20:33:00 GMT

Solutions are processes operating on data. It follows that any change to existing solutions will probably involve changes to processes and data requirements. Process requirements can be expressed in BPMN and many other process modeling notations. Data requirements (as opposed to database design requirements - these are logical requirements that the solution has which are relevant to data and have NOTHING at all to do with database design) model the logical data requirements. Logical data requirements should be expressed in notation that focuses only on the logical data requirement and not the solution that might or might not be used. E.g. classes in UML assume object orientated solutions. Logical data model requirements can be implemented on relational databases, object orientated databases, paper or in someone's head. They are not technology dependant: they just state the logical data requirements that must exit in order for processes to deliver the project objectives.

E.g. A requirement exists to be able to offer add-on sales during the order taking process. The order taking process will change to reflect this. The data requirements mean that items offered for sale also have to have relationships established that represent other items that could be offered as add-on sales for the original item. New data requirements will typically require new processes to maintain the required data logical structure. Modeling the data requirements in 3NF means

1. the minimum amount of data is stored the minimum amount of times.

2. logical inconsistencies are prevented by the data structure itself - e.g. it is impossible to offer a customer postage and packing as an add-on sale item as postage and packing are not related to sale items as add-on candidates.

3. business rules associated with the data will be propagated automatically to any process that attempts to create, read, update, delete (CRUD) that data and do not have to be endlessly repeated by all processes that use the data in the processing logic.

4. data requirements (unlike processing requirements) are relatively stable: while the process for order taking changes every year or so, the fact the company sells items and takes payment does not.

How would you prove that an Entity Relationship Diagram (ERD) was in Third Normal Form (3NF)?

Guy Beauchamp — Mon, 10 Dec 2007 20:25:00 GMT

Third normal form of an ER Diagram (ERD) boils down to every attribute depends on the whole primary key of the entity. Inspect the data model to verify

1. every entity has a business primary key (i.e. a key meaningful to the business, not to the database designers!).

2. no attribute in an entity will vary if the value of another attribute is changed (note: the primary key can not be updated once created).

3. no attributes could ever have null values.

4. there are no repeating groups of attributes in the entity.

There is a data modeler’s joke that you can use to lighten the interview (but not recommended for real world parties!): normalization was (in part) created by Ted Codd - a model is in 3NF when every attribute depends on the primary key, the whole key and nothing but the key - so help me Codd!